今天來介紹「日誌事件與可歸責性」的構面,留存 log 最主要的目的是為了在系統發生被攻擊或無法正常運作時,能在事後透過 log 進行事件分析或偵察、鑑識等,釐清資安事件的發生時序與來源。
訂定日誌之記錄時間週期及留存政策,並保留日誌至少六個月。
內容
機關需針對 log 的留存訂定相關規範,例如作業系統 log、網站 log、應用程式日誌 log、登入 log 等,且至少需要保存 log 6 個月。
實務作法
訂定 log 留存規範。
確保資通系統有記錄特定事件之功能,並決定應記錄之特定資通系統事件。
內容
系統應在發生可能有資安風險的事件發生時,將該事件記錄於系統 log,且機關應評估需要被 log 記錄的事件種類,以免有太多非必要的事件記錄於 log 中,造成難以找到真正需要的事件記錄,或是造成系統效能跟儲存空間不足的問題。
實務作法
建議可以留存以下事件記錄:
應記錄資通系統管理者帳號所執行之各項功能。
內容
由於系統管理者擁有最高權限,不論是故意或非故意的操作,都有重大風險,而遭到入侵時,駭客也經常取得管理者權限,因此需要記錄管理者所有的操作記錄。
應定期審查機關所保留資通系統產生之日誌。
內容
機關需要定期查看、分析系統 log,才能掌握是否曾經發生資安事件,例如異常存取、系統錯誤等。
實務作法
可利用日誌管理(例如 Splunk)或 SIEM,自動收容設備日誌,並進行分類、關聯分析、觸發告警、產製報表等功能,幫助權責人員能快速分析與審查 log,找出可能為資安事件的記錄,減輕管理負擔。
資通系統產生之日誌應包含事件類型、發生時間、發生位置及任何與事件相關之使用者身分識別等資訊,採用單一日誌機制,確保輸出格式之一致性,並應依資通安全政策及法規要求納入其他相關資訊。
內容
Log 需要詳細記錄事件內容,包含人事時地物等關鍵資訊,例如帳號、時間、執行的功能、存取的資源、事件類型、執行結果、事件描述、事件發生當下相關物件資訊、網路來源與目的位址,
以及錯誤代碼等。
Log 的格式需要統一,例如日期格式、Log 框架等,以免導致 Log 的可讀性降低。
且應確保 Log 內容有包含法規、政策、標準所要求的資訊。
實務作法
可利用 .NET Logger、Log4NET、Java Util Logging、Log4j 等元件產生 Log,且不同時混用超過一個的 Log 元件。
(Log 輸出格式不一致的範例,來源:資通系統防護基準驗證實務)
依據日誌儲存需求,配置所需之儲存容量。
內容
應配置足夠的容量供 Log 存放,並定期檢查。
實務作法
資通系統於日誌處理失效時,應採取適當之行動。
內容
需要識別可能造成 Log 處理失效的狀況,並評估可能的危害。
實務作法
可評估在合乎規範的情況下,針對不同的 Log 類型選擇不同的動作,例如覆寫最舊的 Log、利用 email 警告相關人員等。
機關規定需要即時通報之日誌處理失效事件發生時,資通系統應於機關規定之時效內,對特定人員提出警告。
內容
應依照資安政策或相關規定,定義需要及時通報的特定事件、時效與通知對象。
若機關沒有訂定管理辦法,則應《資安事件通報及應變辦法》和其他相關法規執行。
實務作法
例如當 Log Server 無法連線時,以 Email 或簡訊通知系統管理員。
資通系統應使用系統內部時鐘產生日誌所需時戳,並可以對應到世界協調時間(UTC)或格林威治標準時間(GMT)。
內容
系統時間應為正確時間,並避免使用少見的時間格式。
實務作法
可以使用 UTC、GMT、或 UTC+(-)時區表示時間。
系統內部時鐘應定期與基準時間源進行同步。
內容
系統時間應定期校正,並為確保時間正確。
實務作法
設定與 NTP Server 自動同步時間,例如 AD Server 與外部 NTP Server 同步時間,AD 成員主機再與 AD Server 同步時間。
對日誌之存取管理,僅限於有權限之使用者。
內容
因為 Log 可能有機密資訊,所以需要禁止未授權的使用者對 Log 進行任何操作。
實務作法
可利用實體環境控管、系統帳號權限管理或其他控管機制達成。
應定期測試備份資訊,以驗證備份媒體之可靠性及資訊之完整性。
內容
可分為事前預防、事中監視、事後驗證三個階段進行,防止 Log 被竄改、或於被竄改時進行告警、懷疑資料真實性時可驗證是否遭到異動。
實務作法
事前預防:
事中監視:
事後驗證:
定期備份日誌至原系統外之其他實體系統
內容
需要定期將 Log 備份到其他的獨立系統,以免 Server 毀損時,導致備份資料一起消失。
實務作法
可將 Log 備份至 NAS、Log Server、雲端硬碟、磁帶等存放備份資料。